Keep orthographic projections consistent #2020
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a map that uses an orthographic projection, such as Mapper sets up for an import from OpenStreetMap. Test that a track template is positioned correctly. Behavior of PROJ with +proj=ortho changes at version 7.2. A change in alignment within a map is undesirable. OpenOrienteeringGH-2016
PROJ changes its interpretation of +proj=ortho at version 7.2. Using +f=0 in the spec string forces a spheroidal variant of the projection, which is compatible with all earlier versions of PROJ. This commit changes all explicit occurrences of +proj=ortho.
Add the ensureOrthoIsSpheroidal method which will change a PROJ spec string that uses the 'ortho' projection into one which is explicitly spheroidal, with 0 flattenting, by ensuring that '+f=0' is part of the spec string.
When loading a map in XML format, there may be references to a CRS spec with a PROJ string containing '+proj=ortho'. Prior to PROJ 7.2 these were handled as spheroidal orthographic projections. Retain that same interpretation, even if Mapper is built with PROJ 7.2, by calling 'ensureOrthoIsSpheroidal' whenever a spec string is loaded from a map.
Prior to PROJ 7.2, a spec string containing '+proj=ortho' was handled as a spheroidal orthographic projection. Ensure that Mapper handles such orthographic projections consistently by inserting '+f=0' if necessary. In particular, make '+f=0' explicit when the spec is supplied in the georeferencing dialog, by calling 'ensureOrthoIsSpheroidal'.
|
#2080 reported georeferencing problems that arose in the context of the spheroidal orthographic projection. As a result, I have become unhappy with this PR, because it entrenches Mapper's use of the spheroidal projection. |
|
I developed PR #2092, which I prefer to this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PROJ is changing the way it handles '+proj=ortho' in spec strings, as of version 7.2. Previously, that projection performed a spheroidal calculation, even with the WGS84 datum. With the change, PROJ uses the precise ellipsoidal shape when projecting.
I encountered and reported this in #2016, because I build Mapper on Linux where PROJ has been at version 7.2 for several months. The new PROJ alters the geographic coordinates of map objects, changing their alignment to georeferenced templates.
This PR includes a regression test of a GPX track template that fails with the latest PROJ due to the track becoming misaligned with the map. It also addresses the problem by inserting '+f=0' into every spec string that uses '+proj=ortho'.
The drawback to this way of keeping Mapper consistent is that it eliminates the possibility of using an ellipsoidal orthographic projection with Mapper, for the time being. The ellipsoidal version is superior, but probably does not matter for orienteering because the spheroidal projection distorts the scale by less than 1%. It looks to me that if this PR is accepted, then to regain support for ellipsoidal orthographic projections would require a new version of the XML file format, and a bigger code change than this one.